MySQL: kill 会话的实现原理

最近看了丁奇老师的mysql课程中 kill session的部分，在平时的工作的做，我们也经常用kill 命令进行杀掉某些会话，偶尔也会出现状态还是killed的情况，不由得感觉需要研究一下kill 会话的是如何实现的。刚好丁奇老师的这段提供了理论基础。

先要简单的梳理一下语句的执行的生命周期：

打个比方我们以如下的执行计划为列子：

这里涉及到了一个mysql客户端进程和一个mysqld服务端线程，他们通过socket进行通信。如果我们要要kill某个会话我们显然一般是新开起来一个mysql客户端进程连接到mysqld服务端显然这个时候又需要开启一个服务端线程与其对接来响应你的kill命令那么这个时候图如下：

image.png

如图我们需要研究的就是线程2到底如何作用于线程1，实际上线程之间共享内存很简单这是线程的特性决定的，在MySQL中就共享了这样一个变量THD::killed，不仅线程1可以访问并且线程2也可以访问 。实际上这种情况就是依赖在代码的某些位置做了THD::killed的检查而实现。先大概先描述一下这种情况kill 会话的过程

上面已经描述了一个select语句的kill的流程，但是并非都是这种情况，我稍微总结了一下可能的情况：

注意上面的情况都是待杀线程处于的情况，而发起命令的线程只有一种方式，就是调用kill_one_thread函数。下面我将详细描述一下。对于唤醒操作参考附录的内容，我这里就默认大家都知道了。

下面是栈帧：

ERROR 2013 (HY000): Lost connection to MySQL server during query

然后会终止等待进入innodb连接，然后还会做唤醒操作，关于为什么要做唤醒操作我们后面再说如下：

这种情况就是通过在代码合适的位置检查返回值完成了，比如下面栈帧：

我们可以在函数ha_innobase::general_fetch中找到这部分代码如下：

这里ret如果等于DB_INTERRUPTED就会进入线程退出逻辑，具体逻辑我们后面再看。

而其中DB_INTERRUPTED则代表是被杀死的终止状态，由如下代码设置(所谓的"埋点")：

其中trx_is_interrupted很简单，代码如下：

我们可以看到thd->killed正是我们前面发起kill线程设置的THD::killed为THD::KILL_CONNECTION，最终这个错误会层层返回，最终导致handle_connection循环结束进入终止流程。

这种情况和上面类似也是需要检查线程的THD::killed状态是否是THD::KILL_CONNECTION，但是我们知道如果处于pthread_cond_wait函数等待下，那么必须有其他线程对其做唤醒操作代码才会继续进行不然永远会不跑到判断逻辑，我们先来看一下等待栈帧

这种情况就需要有一个线程唤醒它，但是这里唤醒是Innodb层和上面的说的MySQL层唤醒还不是一个事情(后面描述)，到底由谁来唤醒它呢，我们可以将断点设置在：

我们稍微检查一下lock_wait_check_and_cancel的代码就会看到如下：

我们看到关键地方trx_is_interrupted做了对THD::KILL_CONNECTION的判断，当然这个线程还会做Innodb 行锁超时的唤醒工作，这个线程我们可以看到的如下：

| 35 | 4036 | innodb/srv_lock_timeout_thread | NULL | BACKGROUND | NULL | NULL |

如果对于正在执行的语句，需要回滚的会在随后做回滚操作如下：

总的说来Innodb中正是通过丁奇老师所说的"埋点"来判断线程是否已经被杀掉，其"埋点"所做的事情就是检查线程的THD::killed状态是否是THD::KILL_CONNECTION，这种埋点是有检测周期的，不可能每行代码过后都检查一次所以我大概总结了一下埋点的检查位置：

实际上可以全代码搜索什么时候将ret = DB_INTERRUPTED; 的位置就是Innodb层的"埋点"。

这种情况就比较简单了。在空闲的状态下，待杀死线程会一直堵塞在socket读上面，因为发起kill线程会关闭socket通道，待杀死线程可以轻松的感知到这件事情，下面是net_read_raw_loop中截取

这样handle_connection循环结束，进入终止流程。这种情况会在release_resources中clean_up做回滚操作

还记得前面我们的发起kill线程调用THD::awake的时候最后会做唤醒操作吗？和Innodb层行锁等待一样，如果不唤醒那么代码就没办法推进，到达不了Innodb层中设置的埋点位置，下面我用sleep为例进行描述。首先我们先来看看sleep的逻辑，实际上在 Item_func_sleep::val_int 函数中还有如下代码：

这里我们来证明一下，下面是sleep线程的栈帧：

注意这里结构体cond=0x7fffec061510的地址，最终他会传递到THD中，以致于其他线程也能后拿到，我们再来看看THD::awake唤醒的条件变量的地址如下：

我们可以到看到也是0x7fffec061510，他们是同一个条件变量，那么也证明了确实是THD::awake最终唤醒了我们的sleep。代码得以继续，继续后会达到"埋点"，最终handle_connection循环终止达到终止流程。

最终在handle_connection 的循环达到退出了条件，进行连接终止逻辑如下：

这里我们发现会经历几个函数end_connection/get_stmt_da()->reset_diagnostics_area()/release_resources 然后来到了thd_manager->remove_thd(thd)，最终这个链接会被重用。实际上直到release_resources做完我们才会看到show processlist中的状态消失。可以修改代码，在release_resources函数前后加上sleep(10)函数来验证，如下：

sleep(10);thd->release_resources();sleep(10);

得到的测试结果如下：

可以看到大约10秒后才Killed状态才消失，而Killed状态没有出现20秒因此可以确认是这一步完成后Killed线程才会在show processlist中消失。

我们有对 thd->release_resources();做详细研究，就是这个函数执行完成过后Killed线程不会出现到show processlist中。如果有同学有兴趣可以深入学习。其实在Oracle中我也遇到很多kill session 标记为killed的情况，相信原理都差不多。下次在遇到killed状态的线程也不用急，可以看看这个线程是否正在干活，主要看看这个线程是否占用了CPU了，如果没有干活肯可能出现的BUG，比如某些Mutex的锁等待(如上列)。 附录：

一些关于posix多线程编程的函数接口 参考我的文章： http://blog.itpub.net/7728585/viewspace-2139638/

这里截取部分内容：

在线程同步中我们经常会使用到mutex互斥量，其作用用于保护一块临界区，避免多线程并发操作对这片临界区带来的数据混乱， POSIX的互斥量是一种建议锁，因为如果不使用互斥量也可以访问共享数据，但是可能是不安全的。 其原语包含：

而条件变量cond则代表当某个条件不满足的情况下，本线程应该放弃锁，并且将本线程堵塞。典型的 生产者消费者问题，如果生产者还没来得及生产东西，消费者则不应该进行消费操作，应该放弃锁，将 自己堵塞，直到条件满足被生产者唤醒。原语包含：

注意这里就绑定了一个互斥量，也就是说条件变量一般和某个互斥量配套使用，因为单独的条件变量达不到任何堵塞线程的目的